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(57) Abstract: The invention is a method for a multiple smart card simiUator. 
The invention allows cards with different characteristics such as memory, com- 
mand sequence, error handling, and data flow to be simultaneously simulated. It 
also permits simultaneous simulation of different smart card user applications. 
The method involves determining the characteristics of smart cards, and then 
modifying input and output to or from these cards based on the smart card char- 
acteristics. In this way, an end-to-end simulation environment is provided. 
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Title: METHOD FOR A MULTIPLE SMART CARD SIMULATOR 

This application claims priority from U.S. provisional application 60/138,679 filed Jime 14, 1999. 
Field of Invention 

The present application relates to a method for a multiple smart card simulator, and in particular, an 
application employing multiple simulated smart-cards where the applications running. on» or enabled 
on, some of the smart cards differ from those applications running on, or enabled on, other of the 
simulated smart cards, and where the smart cards may have different characteristics. 

Background to Invention 

Smart cards are hardware devices that typically have the shape and size of a credit card. Often they 
have an embedded computer processor, memory and an operating system. Oflen smart cards have 
stored in their memory information related to the user of the smart card. Such information can 
include: 

(i) personal information, such as name, address, other contact information, date of birth, 

etc.; 
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(ii) financial infonnation, such as bank account numbers and type of account, account 
balances and transaction histories, retirement savings plan information, investment 
information and investment portfolio and account information; 

(iii) medical information, such as medical history and known allergies and prescription 
history; 

(iv) information related to retail shopping, such as clothing sizes, shopping histories and 
product, preferences; and 

(v) other information relating to taste, style and economic, social or cultural activity. 

Smart cards are inserted into card terminals which may include automated teller machines, internet 
kiosks, pay telephones, point of sale terminals, cellular phones, or any device containing a card 
reader. 

Using the information stored on the smart card, the card terminals provide a variety of services and 
computer-based applications to the user of the smart card. These services can include: 

(i) paying bills, transferring money between accounts, making investments, analyzing 
a portfolio; 
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(ii) ordering prescription drugs, providing infoimation to health care professionals oi 
receiving information frona them; 

(iii) buying or selling consumer goods, receiving product information, participating in 
consumer surveys, receiving promotional offers, customizing products; and 

(iv) playing games or receiving other content such as music, video, text or images. 

Different users of smart cards may want to use different applications for a variety of reasons: smart 
cards may have different capabilities, users may have different needs and preferences, users may be 
authorized to use different applications. 

Developers of smart card applications often prefer to develop tiiese applications in a simulated 
environment In the simulated environment, many hardware elements of the system such as the 
smart card, cardreader and card terminal are simulated. This allows tiie developer to test and 
develop function, eliminate error, and imjwove performance of die system witiiout the cumbersome 
and costiy need to implement all of the hardware elements. 

Current simulation environments, such as the Java Card™ simulation environment suffer the 
drawback tiiat they are unable to simulate an application Uiat deals with multiple smart cards where 
those smart cards have different applications or where the smsirt cards have different characteristics. 
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Siimmarv of Invention 

The purpose of the present invention is to provide a method and apparatus for simulating a smart- 
card-based computer application. 

An advantage of the invention is that it supports multi-application card environments. Another 
advantage of the present invention is that it alloAvs simultaneous simulation of smart cards with 
different characteristics. A further advantage is that it allows simulation of the smart card, card 
reader, tenninal, and user application in a single development workstation. 

In one embodiment of the present invention there is provided a method for a multiple smart card 
simulator. 

Description of Figures 

Figure I shows a flow chart describing an embodiment for the present invention; 

Figure 2 shows a flow chart describing an embodiment for the present invention; 

Figure 3 shows a flow chart describing an embodiment for the present invention. 
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Detailed Description 

Smart cards often have different characteristics. These characteristics include available memory, the 
manner in which they handle error conditions, the command sequence to be input or the data 
returned from a command sequence. Smart cards often also have idiosyncratic quirks or bugs. 
These characteristics and quirks must be simulated in order to have an effective simulation. 

The present invention provides a method for providing a multiple smart card simulator. In one 
embodiment, as set out in figure 1, the following steps occur: 

(i) storing a first set of characteristics of a first smart card (step 1 00). These are stored 
in memory in the developer's workstation; 

(ii) creating a first smart card simulator simulating operation of said first smart card (step 
105). The simulator operates by processing data in the same way that a real smart 
card would; 

(iii) storing a second set of characteristics of a second smart card (Step 1 1 0); 
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(iv) simulating operation of said second smart card thereby creating a second smart card 
simulator (step 1 1 5). The simulator operates by processing data in the same way that 
a real smart card would; 

(v) receiving a first input from a first smart card application (step 130). As used herein, 
smart card applications refer to user applications running on the developer's work 
station or on a simulated terminal and not to thin or trivial applications running only 
on the smart card; 

(vi) modifying said first input based on said first set of characteristics (step 140); 
(vii*) sending a first modified input to said first smart card simulator (step 1 50); 

(viii) modifying said first input based on such second set of characteristics to form a 
second modified input; and sending the second modified input to said second smart 
card simulator (steps 1 55 and 1 60). The second simulator needs a different modified 
input because it has different characteristics; 

(ix) receiving a first output from said first smart card simulator generated in response to 
said first modified input (step 170). The output is generated by the simulator by 
methods known to those skilled in the art; 
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(x) modifying said first output based on said first set of characteristics to form a first 
modified output (step 1 80); 

(xi) transmitting said first modified output to said smart card application (step 190); 

(xii) receiving a second output from said second smart card simulator generated in 
response to said second modified input (step 200). The output is generated by 
means to those skilled in the art; 

(xiii) modifying said second output based on said second set of characteristics to form a 
second modified output (step 210); 

(xiv) transmitting said second modified output to said smart card application (step 220); 

In another embodiment, a method is provided for simultaneously nmning different applications on 
different smart cards. This method is shown on Figure 2 and comprises the following steps: 

(i) receiving a second input from a second smart card application (step 300); 

(ii) modifying said second input based on said first set of characteristics (step 310); 

(iii) sending a third modified input to said first smart card simulator (step 320); 
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(iv) 



receiving a third output from said first smart card simulator in response to said third 



modified input (step 330); 



(V) 



modifying first said third output based on said first set of characteristics (step 340); 



(vi) transmitting said third modified output to said second smart card application (step 



One important aspect of the invention is the ability to simulate card insertion. Depending on the 
characteristics of the inserted card, different applications may be downloaded into the card. This 
method is shown in Figure 3 and comprises the steps: 

(i) generating a simulated smart card insertion (step 400); 

(ii) determining characteristics of the inserted card (step 405); 

(iii) notifying registered listeners (step 410); 

(iv) determining available applications (step 420); 



350); 



8 



wo 00/77750 



PCT/CA00y00703 



(v) downloading to a simulated smart card and to a simulated terminal at least one smart 
card application (step 430) and 

(vi) repeating (steps 400 - 430) * 

In the above methods it may be advantageous to simulate Java Cards, for which many development 
tools currently exist and for which the same program code can run in the actual smart card and in the 
simulator, namely the Java progranmiing language. 

Further details are set out in appendix A "Alchemy: Science and Magic for Intelligent Devices" 
especially sections 5 and 5.1 and in co-pending U.S. applications 09/332,069 titled "Method and 
Apparatus for Incremental Download from Server to Client", 09/332,191 titled "Mediod and System 
of Deploying an Application between Computers", 09/332,192 titled "Method and System for 
Remotely Observing and Controlling Objects and 09/332,193 titled "Method and System for 
Managing and Using Persistent Storage all of which are incorporated by reference. 
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We claim: 



1 - A method of providing a multiple smart card simulator comprising: 



(i) storing a first set of characteristics of a first smart card; 



(ii) creating a first smart card simulator simulating operation of said first smart card; 



(iii) storing a second set of characteristics of a second smart card; 



(iv) simulating operation of said second smart card thereby creating a second smart card 
simulator; 



(v) receiving a first input from a first smart card application; 



(vi) modifying said first input based on said first set of characteristics; 



(vii) sending a first modified input to said first smart card simulator; 
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(viii) modifying said first input based on such second set of characteristics to form a 
second modified inpu^ and sending the second modified input to said second smart 
card siihulator; 

(ix) receiving a first output from said first smart card simulator generated in response to 
said first modified input; 

(x) modifying said first output based on said first set of characteristics to form a first 
modified output; 

Cxi) transmitting said first modified output to said smart card application; 

(xii) receiving a second output from said second smart card simulator in response to said 
second modified input; 

(xiii) modifying said second output based on said second set of characteristics to form a 
second modified output; and 

(xiv) transmitting said second modified output to said smart card application. 

The method of claim 1 where said characteristics include one of the smart cards memory 
size, command sequence, error handling routine or quirks. 
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The method of claim 1 further comprising the steps: 



(i) receiving a second input from a second smart card application; 



(ii) modifying said second input based on said first set of characteristics; 



(iii) sending a third modified input to said first smart card simulator; 



(iv) receiving a third output from said first smart card simulator in response to said third 
modified input; 



(v) modifying first said third output based on said first set of characteristics; 



(vi) transmitting said third modified output to said second smart card application. 



A method of simulating a multiple smart card environment comprising: 



(i) detecting a simulated smart card insertion (step 400); 



(ii) determining characteristics of the inserted card (step 405); 
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(iii) notifying registered listeners (step 410); 

(iv) detemining available applications (step 420); 

(v) downloading to a simulated card and to a simulated terminal at least one smart card 
application (step 430) and 

(vi) repeating (steps 400 - 430). 
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Figure 1 
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Figure 2 
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Figure 3 
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IVffiTHOD FOR A MULTIPU; SMART CAW> SIM^^ 

This application claims priority jfrom U.S. provisional q>p]ication 60/138,679 
5 ffled June 14, 1999. 

Field of Inveation 

The present application relates to a method for a multiple smart card simulator, 
and in particular, an application employing multiple simulated smart-cards where 
10 the applications running on, or enabled on, some of the smart cards differ from 
those appUcations running on, or enabled on, other of the simulated smart cards, 
and where the smart cards may have different characteristics. 

Background to Invention 
15 Smart cards are hardware devices that typically have the shape and size of a credit 
card. Often they have an embedded computer processor, memory and an 
operating system. Often smart cards have stored in their memory information 
related to the user of the smart card. Such information can include: 

20 (i) personal information, such as name, address, other contact 

information, date of birth, etc.; 

(ii) financial information, such as bank account numbers and type of 
account, account balances and transaction histories, retirement 
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savings plan informatioii, investment information and investment 
portfolio and account information; . 

(iii) medical information, such as medical history and known allergies 
5 and prescription history; 

(iv) information related to retail shopping, such as clothing sizes, 
shopping histories and product, preferences; and 

10 (v) other inforination relating to taste, style and economic, social or 

cultural activity. 

Smart cards are inserted into card temnnals which may include automated teller 
machines, internet kiosks, pay telephones, point of sale terminals, cellularphones, 
15 or any device containing a card reader. 

Using the information stored on the smart card, the card terminals provide a 
variety of services and computer-baised applications to the user of the smart card. 
These services can include: 

20 

(i) paying bills, transferring money between accounts, making 
investments, analyzing a portfolio; 
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(ii) ordering prescription drugs, providing information to health care 
professionals or receiving information from them; 

(iii) buying or selling consumer goods, receiving product information, 
> participating in consumer surveys, receiving promotional offers, 

customizing products; and 

(iv) playing ganies or receiving other content such as niusic, video, 
text or images. 

Different users of smart cards may want to use different applications for a variety 
of reasons: smart cards may have different capabilities, users may have different 
needs and preferences, users may be authorized to use different appMcations. 



15 Developers of smart card applications often prefer to develop these applications 
in a simulated environment, hi the simulated environment, many hardware 
elements of the system such as the smart card, cardreader and card terminal are 
simulated. This allows the developer to test and develop function, eliminate . 
error, and improve performance of the system without the cumbersome and costly 

20 need to implement all of the hardware elements. 

Current simulation environments, such as the Java Card™ simulation 
environment sujSer the drawback that they are unable to simulate an application 
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that deals with multiple smart cards where &ose smart cards have diSereDt 

applications or where the smart cards have different characteristics. 

Smimiarv of Invention 
5 The purpose of the present invention is to provide a method and apparatus for 
simulating a smart-card-based computer application. 

An advantage of the invention is that it siqpports multi-application card 
enviromnents. Another advantage of the present invention is that it allows 
10 simultaneous simulation of smart cards with different characteristics. A further 
advantage is that it allows simulation of the smart card, card reader, terminal, and 
user apphcation in a single development workstation. 

In one embodiment of the present invention there is provided a method for a 
15 multiple smart card simulator. 

Description of Figures 

Figure 1 shows a flow chart describing an embodiment for the present invention; 
20 Figure 2 shows a flow chart describing an embodiment for the present invention; 
Figure 3 shows a flow chart describing an embodiment for the present invention. 
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Detailed Description 

Smart cards often have different characteristics. These characteristics include 
5 available memory, the manner in which they handle error conditions, the 
command sequence to be input or the data returned from a command sequence. 
Smart cards often also have idiosyncratic quirks or bugs. These characteristics 
and quirks must be simulated in order to have an effective simulation. 

10 The present invention provides a method for providing a multiple smart card 
simulator hi one embodiment, as set out in jggure 1, the following steps occur: 

(i) storing a first set of characteristics of a first smart card (step 1 00). 
These are stored in memory in the developer's workstation; 

15 

(ii) creating a first smart card simulator simulating operation of said 
first smart card (step 1 05). The simulator operates by processing 
data in the same way that a real smart card would; 

20 (iii) storing a second set of characteristics of a second smart card (Step 

110); 
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(iv) simulating operation of said second smart card thereby creating a 
second smart card simulator (step 115). The simulator operates 
by processing data in the same way that a real smart card would; 



5 (v) receiving a first input Scorn a fust smart card application (step 

130). As used herein, smart card applications refer to user 
applications nmning on the developer's work station or on a 
simulated terminal and not to thin or trivial applications running 
only on the smart card; 

10 

(vi) modifying said JBrst input based on said iSrst set of characteristics 
(step 140); 



(vii) sending a first modified input to said Gist smart card simulator 
15 (step 150); 

(viii) modifying said first iaput based on such second set of 
characteristics to form a second modified input; and sending the 
second modified input to said second smart card simulator (steps 

20 155 and 160). The second simulator needs a difTerent modified 

input because it has different characteristics; 

(ix) receiving a first output from said first smart card simulator 
generated in response to said first modified input (step 170). The 
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outpiit is generated by the simulator by methods known to those 
skilled in the art; 

(x) modifying said jfirst output based on said first set of characteristics 
5 to form a first modified output (step 1 80); 

(xi) transmitting said first modified output to said smart card 
application (stq> 190); 

10 (xii) receiving a second output from said second smart card simulator 

generated in response to said second modified input (step 200). 
The output is generated by means to those skilled in the art; 

(xiii) modifying said second output based on said second set of 
15 characteristics to form a second modified output (step 210); 

(xiv) transmitting said second modified output to said smart card 
apphcation (step 220); 

20 In another embodiment, a method is provided for simidtaneously running 
different applications on different smart cards. This method is shown on Figiure 
2 and comprises the following steps: 
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(i) receiving a second input from a second smart card application 
(step 300); 

(ii) modifying said second input based on said first set of 
5 characteristics (step 3 1 0); 

(iii) sending a third modified input to said jSrst smart card simulator 
(step 320); 

10 (iv) receiving a third output &om said first smart card simidator in 

response to said third modified input (step 330); 

(v) modifying first said third output based on said first set of 
characteristics (step 340); 



15 



(vi) transmitting said third niodified output to said second smart card 
application (step 350); 



One important aspect of the invention is the ability to simulate card insertion. 
20 Depending on the characteristics of the inserted card, different applications may 
be downloaded into the card. This method is shown in Figure 3 and comprises 
the steps: 



(i) 



generating a simulated smart card insertion (step 400); 
SUBSTITUTE SHEET (RULE 26) 
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(ii) 



detennining characteristics of the inserted card (step 405); 



(iii) 



notifying registered listeners (step 410); 



(iv) 



determining available applications (step 420); 



(V) 



downloading to a simulated smart card and to a Simulated 



terminal at least one smart card application (step 430) and 



10 



(vi) repeating (steps 400 - 430) 

In the above methods it may be advantageous to simulate Java Cards,, for which 
many development tools currently exist and for which the same program code can 
15 run in the actual smart card and in the simulator, namely the Java programming 
language. 

Further details are set out in appendix A "Alchemy: Science and Magic for 
Intelligent Devices" especially sections 5 and 5.1 and in co-pending U.S. 
20 applications 09/332,069 titled ''Method and Apparatus for Incremental Download 
from Server to Ghent", 09/332,191 titled "Method and System of Deploying an 
Application between Computers", 09/332,192 titled "Method and System for 
Remotely Observmg and Controlling Objects and 09/332,193 titled "Method and 



SUBSTITUTE SHEET (RULE 26) 



wo 00/077750 PCT/CAOO/00703 

-10- 

System for Managing and Using Persistent Storage all of which are incorporated 
by reference. 
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APPENDKA 




Alchemy™: 
Science and Magic 
For fnteliigent Devices 
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Acronyms 




Application Programming Interface 



ASCII 



American Standard Code for Information Interdiange 



ATA 



Advanced Technology Attachment 



AWT 



CPM 



Abstract Windowing Toolkit 



Communication Processor Module 



CSO 



DSP 



Chip Select O 



Digital Signal Processing 



DRAM 



Dynamic Random Access Memory 



DSVD 



Digital Simultaneous Voice Data 



DTAD 



Digital Telephone Answering Device 



DTMF 



Dual Tone Muld Frequency 




HTTP 



Hyper Text Transmission Protocol 




Input/Output 



ISDN 



Integrated Services Digital Network 



ISO 



International Organization for Standardization 



ISP 



Internet Service Provider 



JNI 



Java Native Interface 



JVM 



Java Virtual Machine 




LIFO 



Last In, First Out 



NOR Flash 



Negative OR Flash 
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o&c 
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r\j io 


jr Jaiu v/iu X eicpnoiic ocrvicc 


PPP 


Point-to-Point Protocol 


ro AIN 


ruoiic DWitcned lel&paone Network 






KUM 


Read Only Memory 


RTOb 


Real Time Operating System 






SCWTD 


Spontaneous Caller Waiting ID 










UI 


User Interface 


URL 


Uniform Resource Locator 


USB 


Universal Serial Bus 
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1 Introduction 

Advances in Internet; telephony, and other comniunications tedinologies have spurred demand for a wide range 
of new, intelligent devices. Armed with these devices, service providers will soon offer a host of new Internet 
services to a new class of users. Easy access to services will fuel the continuing explosion of the Internet, 
ultimately creating greater demand for intelligent access devices. As a device manufacturer, this is th^ kind of 
chain reaction you want to be right in the middle of... but how do you get in the game? Many devices will be 
deployed including screen phones, counter-top tablets, set top boxes, mobile phones, public kiosks. Personal 
Digital Assistants (PDA), etc. Regardless of the device, there are a couple of things to keep in mmd, if you are 
going to be successful. 

1 . Your device is going to have to be "slick** so you can differentiate yourself from the competition. 

2. The time to market is critical so you will want to compress your development time. 

3 . Development dollars are scarce so use them where they count the most, on the value add content. 

4» People that know how to put Java™ into onbedded appliances are very scarce. Work on getting ihem now. 

5. The Internet is bigger dian you are, so you need a way to integrate the rapidly emerging technologies 
without getting buried- • 

What will it take to get this device developed? 

First, you need a hardware solution. You can probably find a reference design as a starting pomt, but you*re 
going to need to build a development board with the proper features for your device. You need to get started 
right away because it will take 4 to 6 months. Beyond that timeframe, you will also have to spin a form factor 
board, which will take another 4 to 6 months. 

Next, you need a proper oivironment and strategy for software development. You need to develop the software 
parallel'to the hardware because you won't see the hardware for several months, Java*^ is a good choice for 
achieving platform independence and it has "network awareness'* within it Good news comes from your Real 
Time Operating System (RTOS) vendor because he has an embeddable Java solution you can deploy on your 
hardware when if s ready. 

It's not a bed of roses yet... you have a full suite of device drivers to write before integrating your software and 
hardware. Better get your RTOS engineers woricing right away as driver development might end up on the 
critical path. 

Now, let's move to the application suite. The initial set of applications to be deployed is well defined but the 
d^amic nature of the service enviromnent will inevitably give rise to new requirements. You need a solid multi- 
application infrastructure that allows you to react to changing requirements. but there isn't time to do it 
properly for this device. 

So, you take shortcuts and begin to cobble together your ^plication suite. Debuggmg proves to be more 
complicated than expected because the software is multi-threaded. It would be nice to have debugging tools 
tailored to your architecture, but you don't have time or resources to develop tools. You struggle with traditional 
tools and some rudimentary tracing facilities. 

Eventually, you have a "mostly working" application suite and hardware platform. You are ready to begin 
integration but progress is slow. It proves to be non-trivial to configure a target device properly and get a Java™ 
software load onto it. It would be nice to have a seamless environment covering the entire spectrum fix)m the 
Java™ application suite to RTOS and drivers,., but you don'L Debugging on the target is even more challenging 
fhm on the workstation. You probably should have developed those test tools but it's too late now. 

Finally, your applications are running on the target and are close to achieving the functional requirements for the 
device... but you aren't out of the woods yet Your boot time is too slow and your memory requirements are too 
large. You need to re-architect your application suite to improve the milialization sequence. Meanwhile, you find 
tools that can help trim down your Java™ load, but Uiey are not well integrated and prove to be cumbersome. 
You make ^e tools work for you, but you really need to address these environment^ issues before your next 
device. 
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You are ready for field trials, but you bad to pull all your diagnostic capabilities to achieve a representative 
software load. You are now flying blind when it comes to debugging anomalies in the field. It would be great to 
have support for remote management and monitoring of the device. You would double benefit from tiiis when it 
comes time to pwforming automatic regression testing. Put it on the wish list for next time... this device is done! 

It took 18 months to deDver, and cost you over 96-man-months of software effort and 48; man-months of 
hardware resources. You hope you haven't missed your window of opportunity. The next device will go a lot. 
smoother now that you've been through it once. At least you hope so! Don't let this description become a brief 
history of your development effort There is a better way. 



Alchemy^ ^ 

Derived from real world experience gamed in developing two generations of Java-based intelligent devices, 
AudeSi Technologies Inc. delivers Alchemy™, a unique software and hardware solution targeted at rapid 
development. of intelligent devices requiring Internet, telephony, and/or smart card capabilities. 

Alchemy™ includes a Java-based multi-application software framework, a variety of plug-in software services, 
workiiig example applications, and a comprehensive development and test environment that addresses the fiill 
spectrum of device-level software development issues. Alchemy™, when integrated with Touchstone"™ and 
associated drivers, provides a superset of hardware c^abilities required for intelligent devices. This includes a 
PowerPC™ based computation engine, multiple memory configurations, an advanced two-line telephony block, 
smart card readers, and a host of I/O capabilities including Ethernet, modm, serial, and universal serial bus 
(USB). Details on Touchstone™ are included in Appendbc A. 

The primary goal of Alchemy™ is to reduce the barriers to entry for prospective manufacturers and developws 
of intelligent devices. Alchemy™ adiieves these goals by providing the following. 

1. A Java Native Interface (JNI) provides access to TouchstoneTw hardware platform capabilities from the 
Java™ layer, thus eliminating the need for developers to work with low-level device drivers and RTOS 
issues. 

2. The Alchemy™ Core Framework provides a comprehensive environment for the deployment of an 
extensible multi-application software suite. The framework handles a variety of low-level issues including 
device configuration, initialization sequence, and memory/file-system management, thus allowing the 
developer to concentrate on application level development. 

3. The framework is "Internet Aware" and supports seamless integration with network-based server 
environments. Two primary c^abih'ties delivered through network awareness are as follows: 

• Remote device management where a server-abased application can manage a device for the purpose of 
device configuration, software upgrade, or in-field diagnostics. 

• Distributed framework services where applications can be seamlessly partitioned across the 
device/server environment, ultimately reducing device resource requirements by oftloading portions of 
the application onto server resources. 

4. Alchemy™ is based on the JavaBeans™ programming model, and as such, fecilitates development of 
portable and reusable software components, and integration with commeixially available Java™ software 
development tools and environments. 

5. Alchemy™ delivers comprrfiensive services in support of application development including the following: 

• Application services including application registration, application selection, language management, 
and user preference management 

• hitexnet services including point-to-point protocol (???) and integration of 3"* party browsers and 
email clients.- 

• Smart card services including Open Card Framework™ (OCF) and Java Card™ support 
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• Telephony services including voice call control state madiine, dual tone multi frequency (DTMF) tone 
generation, frequency shift keying (FSK) data reception. Calling Line ID/Spontaneous Caller Waiting 
ID (CLID/SCWID), contact database, and modem control. 

• Observation and control services that facilitate remote testing of devices. 

• Device Management Gateway services for secured management of device configuration and 
application dovmload. 

Beyond this initial set of services, Alchemy™ will be continually enhanced with new service offerings in a 
variety of areas including security and cxyptographic support, £-Commerce protocols, personal information 
manager (PIM) services, and advanced Internet and telephony services. 

6. Alchemy*™ includes Rapid Application Development (RAD) objects that leverage available Alchemy™ 
services into functionally complete application implementations. RAD objects can be customized to rapidly 
deliver applications with a device-specific look and feel. 

7. Alchemy™ includes a comprehensive set of develoi»nent tools (e.g., installation tools, system configuration 
tools, debugging and testing tools) that smooth the development process. 

The remaining sections of this pap^ describe the architecture and capabilities that Alchemy™ delivers. 

2 Architectural Overview 

Hie basic architecture of Alchemy™, as deployed on Touchstone™, is shown in Figure 1 . 



DEVICE SERVER 




Figure 1 - Alchemy™ Architecture 
The major components in the device architecture are described below. 
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1 . Touchstone"^ consists of the reference hardware, the RTOS, device driver suite, tbe PJava 
environment and the device driver JHL Touchstone™ cuirdatly supports two commercial RTOS/Java 
environments, namely Sun's JavaOS4C™, and WmdRiver Systans' JWoiics^. 

2. Alchemy '^Core Framework: The firamewoik is fte backbone of fee software architecture, providing a 
dynamically configurable multi-application framework and managed bean repository. Managed beans 
represent the active components in the system, and are directly accessible through tiie framework. The 
framework is also responsible for low-level device infrastructure mcluding system configuration, 
device initialization, communications adapters, memory managem^it, file system, persistent storage, 
and JAR management 

3. Alchemy System Beans: A variety of system beans are provided with Alchemy. These beans give 
other application beans access to system services such as hardware devices, persistent storage, system 

. properties and application support facilities. 

4. Service Beans: General purpose and application-specific capabilities are provided to Ae system 

- through service beans. They are device-independent and reusable in nature. Application beans make 
use of service beans to deliver device-specific application capabilities. While Alchemy™ supplies a 
number of service beans, they are most often associated with specific application functionality (e.g., 
the protocol component of an application). 

. 5. Application Beans: The look and feel of a specific application on a specific device is implemented in 
an application bean. An application bean implements the user interface and interacts with system and 
service beans to achieve tbe application's intended functionality. Alchemy™ provides a numbo- of 
RAD objects that are designed to deliver functional applications quickly. RAD objects can be extended 
or modified to deliver device-specific application features. 

6. Communications Adapter: The communications adapter allows for sever-based communicatioD with 
the framework and all managed beans that are roistered with the fran^ework. Adapters provide a 
mechanism whereby managed beans within the framework can be manipulated remotely through a stub 

OT client bean. Alchemy^" currently supports HTTP and HTTPS communications adapters. 

The Alchemy™ architecture provides direct seamless integration with server applications through the 
framework and communications adapters. While the device/server architecture is general-pujpose in nature^ it is 

currently used within the Alchemy"™ environment to deliver three key capabilities. 

1 . Device Management Gateway: The gateway is part of the Alchemy^" architecture that supports remote 
management of devices. Through a communications adapter, the gateway can interact with tbe framework 
to provide a number of capabilities, including discovery services, device configuration, and application 
download. Discovery services are used to determine the existing configuration of a device, including 
available resources, existing software components, and version numbers. Device configuration services 
allow for remote configuration of the services and applications on the device. Application download 
services allow for upgrades to the device software load, including dovmload of new applications to the 
device. The gateway is fiilly extensible and can be easily incorporated into any server environment 

2. Remote Testing: Because Alchemy™ supports remote interaction with the frameworic and managed beans 
within the framework, it is well suited to remote device testing. Alchemy"^** includes a flexible and 
extensible observation and control architecture that allows a server-based test tool to monitor and control 
the behavior of managed beans within the framework. The observation and control architecture is well 
suited to development time testing, automated regression testing, and in-field tesdng. 

3. Extended Framework: Alchemy™ directly supports the concept of an extended framework where a slave 
framework environment is created on the server and controlled by the device. U^g this mechanism, it is 

^ possible to partition applications in a manner that places most of the application resources on the server 
with only the shell of the application deployed on the device itself. Interaction between the device-resident 
application shell and the server-resident application services is achieved transparently through the 
fi^unework and the communications adapter. 
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3 Alchemy™ Core Framework 

ITie framework is the heart of the Alchemy^" architecture and is responsible for e?tabhshing and 
maintaining all basic system services, and orchestrating the device mitialization sequence. The services 
available in the finmework are described in the following subsections. 

3.1 System Conffguration 

The framework defines the system configuration through a set of system properties. These properties define 
precisely the underlying capabilities of the device and mclude information regarding available memory, 
display capabilities, and the existence of I/O devices such as Etiiemet, USB, modem, smart card reader, etc. 
In essence, the system properties define a subset of Touchstone™ capabilities that are available to a device- 
specific software load. System properties can be defined through a combination of hard-coded, command- 
line, and prop^-file entries. After initialization, system properties are made generally available through 
the standard Java system properties. 

The system properties "can be accessed remotely through discovery services in the gateway. 

3.2 Persistent Storage 

Aichemy^^ relies on the existence of some form of p^istent storage. At a minimum, persistent storage is 
requnred to hold the software load itsel£ To take advantage of the dynamic capabilities of Alchemy, 
writeable persistent storage is required. B^ond storage of the system itself^ the framework controls all 
other persistent storage and makes it available to managed beans within the system, A variety of flavors of 
persistent memory are supported including NAND Flash, NOR Flash, and EEPROM. Touchstone*™ 
provides underlying hardware and driver support for all types of persistent memory. 

Through a set of configuration parameters, &e developer can define any number of contiguous blocks of 
persistent storage within the systems available persistent memory. Once deJBned, these persistent storage 
blocks are available for allocation to managed beans through the framework. The framework is responsible 
for maintaining a persistent map of persistent storage, and returning the blocks to their respective owners at 
start-up. The framework is also responsible for de-allocation of persistent storage and defragmentation of 
persistent memory. 

Although Alchemy*^" does not rely on the existence of a Flash File System (FFS), it does support one. If a 
device is configured with a FFS, it will exist in a contiguous block of Flash and be made available through 
the standard Java file system support. The FFS can co-exist with the block-based persistent storage 
mechanism provided by the framework. 

3.3 JAR Repository 

The Java software load for a system is maintained in Java Archive Storage (JAR) files in persistent storage. 
The JAR Repository is responsible for managing the JARs and adjusting the JVM CLASSPATH to include 
all available JARs. JARs are separated into three categories as follows: 

1 . Java System: The Java System JARs include all the base Java classes the virtual machine (VM) expects. 

2. Alchemy ^'^Systemi The Alchemy"^** System JARs contain the entire core Alchemy""* classes used in the 
system inchiding Alchemy^ utility, system, and service classes. 

3. Application', Application JARs contain the device specific e^plicatioQ and service classes for a system. 

The CLASSPATH is dynamically constructed with Java System JARs first. Alchemy"^" System JARs next, 
and Application JARs last. Withm each subset of the CLASSPATH, JARs are maintained in reverse order 
of theh registration (e.g., last registered JAR is fu^t). In this way new JARs can rq)lace obsolete classes in 
older JARs. The JAR Repository can be managed remotely through the gateway to add and remove JARs 
from the system. The JAR Repository is not dependent on a file system, and all JAR downloads are 
"guaranteed". 
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3 A Managed Bean Repository 

Managed beans represent the active components in the system, and collectively, implement the capabilities 
of the device. The framework is responsible for maintaining a persistent repository of managed beans, and 
making those.beans generally available in the system. ITie following information is associated with each 
managed bean in the system. 

K i^ome: The name used to reference the bean. 

2. /D^A unique identifier for the bean. 

3. Cter. The fully qualified class name for the bean, 

4. Type: The type of bean. 

5. Persistent Storage Block List A list that identifies the persistent storage blocks belonging to the bean. 
When a bean is registered with a repository, it must have a unique name. In turn, tiie bean is assigned a 
T)ennanent unique identifier. A reference to any bean m the repository can be obtained through the 
fiamework using either the name or the ID of the bean. 

3.5 Communications Adapters 

The framework is responsible for establishmg any communications adapters that exist in the system. 
Configuration parameters are used to define whic* adapter is used. Alchemy™ supports HTTP and HTTPS 
adapts. If an ad^ter is not inctoded in the device configuration, remote services will be unavaOable. 

3.6 System Initialization 

The framework is responsible for performing system initialization. The prhnaiy goal of the initialization 
sequence is to bring the device to life quickly and then complete system initiaKzation in the background 
The following phases make up the initialization sequence: 

1 . The framework establishes its environment inchiding system properties, framework, persistent storage 
maps, and managed bean repository. 

2. The framework establishes application services through creation of the application manager. The 
application manager is discussed in section 4.1. 

3. The framework creates and registers all application type managed beans. At registration time, managed 
beans are given the opportunity to perform required mtemal initialization. While not enforceable, 
applications should avoid extensive initialization work at registration time. Wherever possible, object 
creation and initialization within an application should be deferred to the moment that such objects are 
required. 

4. Once all appUcations are registered, control is transferred from the framework to the application 
selector where the default idle application is started. Idle applications are discussed in section 4.1 . 

5. In the background, tiie framework continues to create and register other managed beans m the system 
until It has exhausted the list contained in the managed bean repository. Should a running application 
require access to a bean that has not yet been mitialized, that bean will be created arid registered at the 
time of the request. 



3.7 Idle Detection 

Idleness of a device can be used to trigger a number of activities ranging from activation of a screen saver, 
to performing systems maintenance activities such as defragmentation of persistent storage. Alchemy"^* 
provides an idle management service that controls the idle detection process and dispatches events 
indicating system idleness. Two mechanisms are provided for indicating activity in the system. 

1. Spontaneous: The idle manager provides a direct API used to indicate current activity. Any object in 
the system can indicate current activity by makmg this call. 
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2. Polimg: Objects in the system can act as polled activity sources by registering with the idle manager 
The maoagor uses a configurable idle timer to set the polling period On each timer expiration the 
manager polls each source for activity status. 

On each idle timer expiration, the manager decides if the device has been idle during that period. If it has 
the manager generates events to all idle listeners. Idle events incfede an idle count indicating the current * 
number of consecutive idle periods. Listeners can use this count to distmguish between varying levels of 
idleness. Hie idle managanent architecture is illustrated m Figure 2. 




Figare 2 Idle Management Architecture 



4 Application Services 

One of Alchemy's primary goals is to provide an environment that allows the developer to focus on 
application-level development Towards this goal, Alchemy^« provides an extensible multi-applicaUon 
architecture in which applications can co-exist In addition, Alchrany^ provides a number of common 
application services and RAD objects that further reduce the development cycle for applications. 
By definition, an application must include some user interface component (a means by which the user 
mteracts with the appUcation). Unlike traditional computing environment^ it is not a certain^ that an 
mteUigent device will mcbde a full-featured, point-and-click windowing environment in which the user 
interface (UI) can be deployed. Alchemy™ provides the necessary infrastracture to support the followine 
display environments. ^ 

1 . Abstract Windowing Toolkit (A W7) Windowing Environment: This is the standard Java GUI 
environment that supports graphics, windows, and a pointing device. Standard A WT-based drawing 
components and event mechanisms are applicable to this environment 

2. Sea-of-Dots Graphics Environment: This type of display supports rudimentary bit-mapped graphics 
icons, and text. A pomting device is not normally associated with this environment Configurable soft 
keys may be associated with this environment 

3. Alphanumeric Display Environment This type of display supports some number of lines and columns 
of a^)hanumeric style text and fixed-size icons. Configurable soft keys may be associated with this 
environment 

Alchem/s application services are organized into display-independent and display-dq)endent capabilities 
Display-mdependent services include the multi-application architecture, options management, and language 
management, which are described in section 4.1 through 4.3. Display-dq)endent. services for the diree 
display environments are described after the display-independent services. 
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NOTE: The first release of Alchemy™ includes only AWT-dependent display services. Sea-of-dots and 
alphahuineric display services are deferred to a sabsequent release of Alchemy. 

4.1 Multi-Application Architecture 

The multi-application architecture in Alchemy"™ is supported througji an Application Manager that 
provides three basic services as illustrated in Figure 3 and desc^*bed below: 

1 . Application Registration: Before applications are available for selection they must be register^} with 
the Application Manager. The registry maintains a reference to each application and can activate and 
deactivate applications on demand. Within the registry, a single application is identified as the idle 
application, which is activated automatically at start-up» and whenever the device becomes idle. The 
registiy also generates events indicating when the set of applicatims is modified. This event 
mechanism supports dynamically modi^mg the set of available applications. 

2. Application Sdectim: Applications are given focus and made active by the user through an application 
selector. Hie application selector mteracts with the r^istxy to present the user with a selection of 
available applications and effects the activation of applications when they are selected. By definition, 
an application selector inchides some UI component, and as such must be implemented for a specific 
display environment. Alchemy™ provides both display-independent services frar plication selectors 
as well as display-specific RAD implementations of application selectors. 

3. Application History: A history is maintamed when applications are activated and de-activated. When 
an active application is deactivated, the application history determines which application should be 
activated. AlchemyT" provides the base services for application history, as well as a RADO 
implementation of a configurable^ fixed-depth, LIFO history. 




Figure 3 - Multi-Application Architecture. 



4,2 Options Management 

Most device environments have a reqmrement for persistent, user settable options. These options range 
from global options that apply across die entire device (e.g., language preference), to application or service 
specific options. While the scope of options may vary, user access to options is typically available through 
a common access point In a dynamic application environment it becomes necessary for options 
management to become dynamic as well. Alchemy™ provides an extensible options management service 
that facilitates the organization of options, without imposing a specific implementation of options 
management at the UI level. The options service in Alchemy™ provides a base infrastructure .tfiat includes 
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an options menu object capable of supporting a hirararchicaliy representation of options and submenus of 
options, and an abstract option screen object irom which an actual options editing implementation can be 
derived. Furthermore, the options manage contains a mechanism for identifying start-up options that must 
be set on initial stert-up or each time the device is activated; The options management architecture is 
illustrated in Figure 4. 



.vic^^AppncatJOnii^v:} 



Invocation 
Indications. 



Startup ^ 
List 




Menu . 
Helrarchy 



Options 
Screens 



Figure 4 - Options Management Object Relationship 



Key elements of the options architecture are as foUows: 

1. Options Management Application: This is the application responsible for presenting the common 
access points to options. 

2. Options Management Service: This Alchemy™ service provides a root menu and a start-up list for the 
system. 

3. Root Menu: This is the root of the options tree. Options and submenus can be added, as required. 

4. Startup List: This is the list of options that need to be initialized at device start-up. These options must 
be set on initial start-up or each time.the device is activated. 

5. Options Screens: These are the actual GUI implementations of options editing screens for the available 
options. 

6. Invocation Indications: Alchemy™ decouples the invocation of an options screen from the user' s 
dismissal of the screen. When the option screen is dismissed, the invocation indication is used to 
inform the controlling application that user manipulation of the options screen is complete. 



4. 3 Language Management 

Alchemy™ provides a language management service that maintams a list of available languages and a 
listener interface that supports notification of language changes. In addition. Alchemy™ provides a base 
language interface and a core language implementation from vrhich ^plication specific language object 
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can be derived Hie language archhecture is. illustrated in Figiire 5 for an application that extends the 
Alchemy*^" core language Interface. 



Language 
List 



Language 
Change Event 




Figure 5 — Class Structure Language Management 



4.4 AWT Services 

In an AWT-style application environment, the developer has access to all AWT services supplied writh 
PJava. While AWT services fonn the basis of the GUI application, Alchemy™ provides a number of 
services, interfaces, and objects that tightly couple the AWT-based application to the muhi-application 
architecture* 



4.4.1 Applications, Icons, and Selection 

AWT applications extend the base application interface with two objects, a generic panels and an 
Alchemy^ specific AWT icon. The panel is used to bouse the GUI for the application itself. Whenever the 
application is activated, the panel is displayed. The icon is used to effect application selection. It contains 
an image associated with the application and a reference to flie application. The icon generates "application 
selected" events when a mouse click occurs on it. The sequence involved in selection of an ai^lication is 
described below and illustrated in Figure 6. 

1 . A mouse click in the application icon generates an "application selected event" which is received by 
the application selector. 

2. The application selector makes a request to the application manager to activate tise explication. A 
reference to the application is supplied from the application icon. 

3. The application manager mforms the application to activate and requests a reference to the application 

display panel. 

4. The application manager displays the panel and control is turned over to the application. 
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Figure 6 - Applic ation Selection 

To speed development. Alchemy^** provides an AWT application RAD object that implements a shell 
application. This RAD object can be extended to achieve specific application fimctionality. 

4.4.2 Application Selectors 

Alchemy™ provides an abstract base class for AWT application selectors. Several RAD AWT application 
selectors are also included with Alchemy™, 

4.4.2.1 Sidebar Selector 

The AWT Sidebar Application selector implements an icon strip along one boarder of the screen that 
contains a set of icons associated with the device. When an icon is selected, its associated application is 
selected and displayed on the remainder of the screen. Scroll bars become active when the nimiber of 
application icons exceeds the available real estate available to the sidebar. The sidd>ar application selector ' 
is illustrated in Figure 7. 




Figure 7 - Sidebar Application Selector 
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4A2.2 Corner Selector 

Tbe AWT Comer Application selector implements a small icoD in the, comer of the screen that expands into 
a grid of application icons. When an icon is selected, its associated application is selected and the selector 
minimizes in the comer. The comer a|}pIication selector is illustrated in Figure 8» 





Figure 8 - Corner Application Selector 



4.4.3 Options Manager 

Alchemy*^" provides a RAD object that implements a pull-dD\vn-menu-based options management 
application. It dynamically maintains the nested options associated with a device, and provides access to 
those options through a nested pull-down menu. The options manager supports options screens fliat are 
implemented as panels. 

4AA Virtual Keyboard 

Because many devices will be toudiscreen-based. Alchemy™ provides full virtual keyboard support 
including an image-based, configurable virtual keyboard^ and a virtual keyboard manager that provides 
tight integration between the virtual keyboard and text fields within an application GUI. 

The virtual keyboard is based on a multi-image architecture where a visible image contains the user's view 
of the keyboard, and an underlymg invisible image provides a mapping to key values. Mouse clicks on the 
visible image are mapped by location (X, Y) onto the invisible image and the corresponding value in the 
invisible hnage is converted into a key value. Tbe virtual keyboard generates all standard AWT key events. 
The vhtual keyboard also supports automated image replacement based on key presses. For example, when 
the shift key is pressed, the keyboard image can be changed to indicate capital letters. 

When active in a system, the virtual keyboard is automatically displayed when a text field gains focus. The 
text field is reproduced on the keyboard and input is accepted from die user. After completion of the entry» 
the keyboard disappears and the text field is updated to contain the appropriate text. While this mechanism 
is automatic and requires no special consideration from the GUI developer to function, it can be 
cumbersome within a GUI hnplementation. First of all, the virtual keyboard covers the text that is being 
edited, so auxiUaiy information associated with the field (e.g., a field description) is h'kely to be hidden. 
Secondly, there is no general-purpose mechanism available to identiiy a particular keyboard style to 
associate with a particular text field. Lastly, moving from field-to-field involves dismissing the keyboard 
when one field is completed and re-displaying it when another field is given focus. Alchemy^ overcomes 
these problems by providing a virtual keyboard manager. 

The virtual keyboard manager tightly couples a set of text fields in a GUI implementation to the virtual 
keyboard by providing the following capabilities. 

1 . A field descriptor can be associated with a text field that is registered with the manago-. This 
description will be displayed on the keyboard while the text is being edited. 
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2. A specific style of keyboard can be associated wife a text field that is registered with the manager. 

3. "Tab-oFdering" can be established for a group of text-fields, ,where the keyboard can be used to 
navigate field-to-field without being dismissed and redisplayed. 

An application environment that leverages the virtual keyboard manager can be made more user-iiiendly 
than one that does not 

Alchemy™ comes with a number of RAD virtual keyboards mcJuding standard qwerty, alphanumeric, and 
keypad styles. 

4.4.5 Activity Source 

In support of idle detection mechanism, Alchemy^ provides a polled activity source for AWT 
environments. This source monitors AWT mouse and key events, and provides an indication of activity to 
the idle manager when polled. This source eliminates the need for individual applications to continually 
indicate activity to the idle manager (based on the premise that if the user is interacting with the device 
through the mot^se or keyboard^ then some application on the device must be active). 

5 Smart Card Services 

An implementation of the Open Card Framework (OCF) is the cornerstone of Alchemy 's smart card 
services. OCF is implemented within Alchemy^ as a service bean and inchides terminal and teraiinal 
factory implementations for the ARP smart card reader, as well as a number of 3"* party readers includmg 
the Gemplus GCR4 1 0 and Litronic 210. Using OCF, it is possible to support any smart card application by 
implementing an OCF service for the card application, and a termmal application that uses the service. 
Alchemy™ includes a number of RADOs that act as example service and temiinal application 
implementations. 

Because Alchemy™ is a dynamic multi-application environment, it is designed to support multi-application 
card environments. To begin with. Alchemy™ provides a card detection service capable of asynchronously 
detecting card msertions and removals, and notifying registered listeners. When a card is inserted, existing 
OCF services are leveraged to determine the available card applications and a list of those applications is 
returned to the listener. Based on this list, an application selector or some other service within the device 
can select and activate a particular terminal/card application pair. 

Alchemy"^" also supports dynamic download of smart card applications including both terminal and card 
resident portions of a smart card application. Download support is delivered through the gateway as 
described in section 8.4. Specific OCF services are available in Alchemy™ which support the actual 
download of applications to the card. 

NOTE: The first release of Alchemy™ includes support for the Java Card environment only. Support for 
MultOS and other multi-^plication environments is deferred to a subsequent release of Alchemy^*^. 

Finally, the OCF service is augmented with observation and control mechanisms that support remote 
monitoring of ISO 78 J 6 messaging at the card tenninal. This capability facilitates debugging and testing of 
smart card applications. The observation and control architecture is described m section 8.1. 

5.1 Java Card 

Alchemy™ provides direct support for the Java Card 2.0 and 2.1 environments Including a full 
implementation of the Java Card simulation environment Simulation support is realized through the Java 
Card simulation manager, which allows the developer to create any number of simulated terminals and any 
number of simulated Java Cards. Each shnulated card can be configured to contain a number of real Java 
Card Applets. The manager controls the insertion and removal of a simulated card into a simulated 
terminal. Once card msertion occurs, the interaction between card applets and card terminal applications 
can occur just as m a real Java Card environment Using the simulated environment, it is possible to 
develop a card applet and terminal application in the workstation environment and dien migrate it to an 
actual terminal/card environment. Alchemy*s Java Card environment is illustrated in Figure 9. 



SUBSTITUTE SHEET (RULE 26) 



wo 00/077750 



PCT/CAOO/00703 



-29- 



Tbe Java Card simulation manager is augmented with observation and control mechanisms that support 
remote control of card insertion and removal^ See section 82 for details. 




Figure 9 - Java Card Environment 



Alchemy *s implementation of OCF contains specific services that support download and deletion of applets 
on a Java Card. This support is leveraged by the gateway to achieve remote management of the application 
suite on a Java Card. See section 8.4 for details. 

6 Telephony Services 

Alchemy^** provides a number of telephony sendees inchding modem support, basic telephony support, 
and advanced telephony support Hiese services are described in the following subsections. 

6.1 Modem Services 

Modem services are based on Javax.comm, which defines a standard mechanism for serial communications 
in Java. The modem service extends the Javax.comm serial I/O API with a modem control API that 
provides the functionality to initialize and configure the modem. The existing implementation is targeted at 
the V.90 modem available on Touchstone™, but die modem service is easily portable4o other modem 
solutions. 

6.2 Basic Teieptiony Services 

The basic telephony services available in Alchemy'^" are closely coupled to the Touchstone™ Telephony 
board capabilities. The basic telephony service bean provides a control API for direct control over telephony 
features, a status API for retrievmg telephony status, and an event listener API for reception of asynchronous 
telephony events. All basic telephony services are summarized in the following table. 
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Table 1: Basic Telephony Services 



Feature/Description 


Control 


status 


Event 


iiuiiauzanon/ivegisier uuntroi 


X 






Volume 








Handset 


A 


A 




Speaker 


Y 
A 


Y 
• A 




CAS Detection 






Y 

A 


FSK Data Reception 






A 


lype J oauer uj 






X 








X 








X 


DTMF Tone Generation 


X 






Ring Detection 






X 


Extension In Use Detection 




X 


X 


Distinct Audible Ring Tones 


X 






Voice Path Control 








Handset 


X 


X 




Handsfiree 


X 


X 




Microphone 


X 


X 




Hold/Mute/CJnmute 


X 


X 




Dial Pad Scan 






X 


Cradle Hook switch Scan 




X 


X 


Hook Switch Control 








On/Offhook 


X 


X 


X 


Flash 


X 




X 



6.3 Advanced Telephony Services 

While the basic telephony services described in the previous subsection provide access to all the telephony 
capabilities of the ARP, and as such, give the developer fine-grained control over these capabilities, the 
onus is on the developer to integrate these capabilities into a functional telephony service. Alchemy'^ 
includes a number of advanced telephony services that provide this higher level of integration, thus 
reducing the development effort required to deploy a telephony application. Advanced telephony service 
include the following: 

1 . Voice Call State Machine: Provides intelligent control of incoming and outgoing voice paths with 
control over handset/handsfree modes, hold, and mute. Also includes persistent volume control for 
both handset and handsfree, and persistent audible ring tone selection. 

2. Hook Switch State Machine: Provides integrated control and feedback of the hook switch and hook 
switch cradle. 



SUBSTITUTE SHEET (RULE 26) 



wo 00/077750 



PCT/CAOO/00703 



-31- 



3. Telephony/Modem Line Sharing State Machine: Proyidts intelligent sharing of the line between 
telephony and modem functionality in a single-line environment 

4. Distinctive Ring Interpretation: Provided the ability to define distinctive ring interpreters that can be 
used in conjunction v^rith CLID and other services to uniquely identify incoming calls. 

5. Audio Streaming and Playback, Provides voice pafe control and decompression streams for the audio 
protocols supported on the ARP. 

6. Contact Database: Provides a cwifigurable contact database that tigjitly integrates with CLDD features. 
Provides underlying capabilities for caller log, preferred name matching, area code striping, etc. 

Alchemy includes a set of RAB objects that implement a full-featured telephony application based on the 
advanced telephony features described above. Hiis application serves as both an example, and a starting • 
point for a device specific telephony application. 



7 Internet Services 

Alchemy^ provides seamless access to the Internet, and as such, is designed to develop "hitemet Aware" 
devices. Specifically, Alchemy™ provides connectfon services, integration of 3"* party Internet applications 
such as browsers, and emaU clients,, and custom URL handling for services and applications that reqiiire 
integration with browser services. . 



7.1 PPP and Auto Dial 

Dialup connectivity to the Internet via an ISP is supported through AJchemy*s Point-to-Point Protocol 
(PPP) and Auto Dial service. The PPP and Auto Dial service maintains a persistent list of ISP 
configurations. Each configuration contains the information required to make an ISP connection, including 
phone number, user ID, password, DNS Addresses, mail server, etc. The PPP and Auto Dial service 
provides an API that supports addition, deletion and selection of ISP configurations. Once selected, a 
particular configuration is used to automatically establish a connection when some other service or 
application activates TCP/IP services. The PPP and Auto Djal service is also remotely controUable through 
observation and control services. 

7. 2 Internet Applications 

Alchemy™ does not reinvent the wheel when it comes to Intemet applications such as browsers and email 
chents. A number of Java-based "erabeddable'' Internet application suites are commercially available from 
3 party vendors, and these application suites can typically be integrated into Alchemy™ with little effort 
Alchemy™ has been demonstrated to work with two Intemet applications suites, namely Sun 
Microsystems* Personal Applications™ suite, and Espial Group^s Escape™ browser and Ebox™ email 
client While Alchemy™ provides mtegration for these application suites, the suites must currently be 
obtained directly fi^m their respective vendors. 

7.3 Custom URL Handling 

The existence of a browser on a device is useful for more than just traditional Ipteinet browsing applications. 
The HTML rendermg capabilities of the browser can be leveraged into other on-device applications to deliver 
UI services. In such an environment, the developer can use custom URL definitions to trigger events in odier 
services or applications. Alchemy™ provides a custom URL dispatching service capable of maintaining a list 
of custom URL types, and a set of listeners for each type. When the browser encounters an unknown URL 
type. It hands it to the dispatcher which, in turn, dispatches the URL to all interested listeners. 
This process is illustrated in Figure 10. 
As an example, consider the following: 

Aichemy:saveToDirectory?name=AudeSi Technologies Inc.&number=M03-.730-7555 
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This URL is not recognized by the hrowscr so it is passed to the Custom URL dispatcher. It is then passed 
to the URL hsteners. One of the listeners is the directory apph*cation that takes the URL and adds-a new 
entry for AudeSi Technologies Inc. 




8 Observation and Control Services 

The c&tributed nature of the Alchemy^ core provides direct support for remote instantiation of objects into 
a device load. Leveraging this mechanism. Alchemy™ delivers a complete observation and control (O&C) 
architecture capable of supporting system debugging, remote diagnostics, automated regression testing, and 
device management 

8. 1 Observation and Control Architecture 

The O&C architecture delivers two key capabilities to the developer. 

1 . Observation: The ability to ^tract information from the system is accomplished by implementing a 
specific observable interface v^ithin an object, and remotely controlling the observation process 
through an observer bean. Actual observations are passed from the device through a remote event 
mechanism. Observations can be generic (e.g., text-based logging) or specific (e.g. ISO 7816 
messaging). ' 

2. Control: The ability to remotely control objects in the system is accomplished by implementing a 
^ecific controllable interface within an object and remotely controlling that object through a controller 
bean. Control functions are typically object specific m nature. 

Alchemy 's^ O&C architecture and its major components are described below and illustrated in Figure 1 1 , 

1. O&C Registry: On the device side, the O&C registry is responsible for maintaining a list of all 
observable/controllable objects in the system. TTie registiy communicates with a remote O&C manager 
to orchestrate a specific O&C session. All observable/controllable objects in the system must register 
with the registry to be actively observable/controllable. 

2. Observable/Controllable Object: Any object in the system is observable/controllable if it implements a 
specific observable/controllable mterface, and it registers itself with the O&C registry. The object is 
manipulated through a mated observer/controller object that knows the specific O&C interface 
implemented by the object 

3. Observer/Controller Managed Bean: On the device side, the Observer/Controller is instantiated as a 
temporary managed bean, and is responsible for manipulating observable/controllable objects of a 
specific type. The observer/controller is remotely controlled by the O&C manager through a matchmg 
client bean on the server side. 
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4. Observer/Controller Client Bean: On the server side, the O&C manager transparently communicates 
with the device side observer/controJler through the observer/controller ch'ent bean. 

5. O&C Manager, The O&C Manager controls the observation process through three primary functions. 
1. The manager mamtains a registiy of observer/controllers' that can be activated m the framework. 

When instructed to do so by some controlling test tool, the manager instantiates and activates an 
observer/controller in the framework. 

D. The manager presents a configuration and control interface for test tools. It identifies all available 
observer/controllers, and allows the test tool to configure, activate and deactivate those objects. 

ULThe manager processes observation events and submits them to observation database. 

6. Observation Database: The Observation Database stores all the observations for a session. Each 
observation is stored wifli a time-stamp, an observation class name, and the actual observation object 

7. T ?st Tool: Any controlling application can act as a test tool. A test tool may present a GUI to the user 
that allows hfan to configure, activate and deactivate observer/controllers in the system, or it may be a 
self-contained automatic test-harness. Test tools interact with the O&C manager to control an O&C 
session, and with the observation database to inspect observations. 





Because the O&C architecture is open and extensible, it can be leveraged to dehver any specific O&C 
capabilities applicable to a particulai; device or service. Alchemy'" provides specific O&C capabilities 
through a number of tools, and observable/controllable objects as described in the following subsections. 

S.2 Alchemy ^^Observer/Controllers 

Alchemy^ provides a number of specific observer/controller objects that can be used directly by the 
developer including the following: 

1 . Text-based Logger: This observer performs generic text-based logging of events, and can be used for 
general-purpose tracing. 
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2. 
3. 



AppliaaionSelecHon Observer: Ttus observer generates observations that indicate application 
selection and dC'Selection activities; api""*""" 

ISO 7816 Obs^er. TTiis observer generates observations for all smart card messagmg that occurs 
between an CX:F terminal and a smart card. t^iB u«i occure 

4. Jw,a C^dSimulatior, Observer/ControUer. This observer/controller interacts with the Java Card 
Simulation Manager to Identify available simulated Java Cards and facilitates simulated insertion and 
removal of those cards mto a simulated tanninal. « "™u 

5. Boric Tel^horv Observer. This observer handles aU basic telephony observations generated by the 
Alchemy™ basic tel^hony service. o j 

^' ^^^'^^"^^^ Observer. This observer generates observations that contain persistent storage block 

generates observations that mcludeafl control commands sent to 

8. PPP cmdAnto Did Observer. This observer generates observations that identify all activities 
associated with PPP connections. 

8.3 Alchemy Probe 

^^^r " '^^^^'"P*"' probing tool, -niis tool provides a controUing GUI that is used to 

establish and control an O&C session. Tlie probing tool was developed to support testing of Afchemy™ 
and as such, works with all Alchemy™ supplied observer/controllers. TTieprobing tool is based on an ' 

acrdiS»sSs;irbS^s:=^js^^^ 

2. »''»cA/K>wte:Devel(^ers can setwatchpomts forparticular Observations Of Inte^ 

3. Filtering: Developers can define filters on the properties of the observations. 

f^t'^J ^"'^"^f"'- V"^ P"''^g P^vides complete integration with the observation database 
for the storage and retneval of observations. You can also archive and playback previous sessions. 

^' ^T^^' necessarily in human-readable form. Theprobing tool provides the 

infrastructure to support custom hiteipreters that can interpret and display specific observations. 

6. Controller Interfaces: The infrastructure supports custom user interfeces that can be used to activate 
the control interface of observer/controllws. 

8.4 Device Management Gateway 

The Device Management Gateway provides remote management faciUties for devices under development 
Molgg'SplS^r'^'^^'''"''^'"^ 

' foSTSisrb:'^^^^^ 

. 1. Syslem Properties: System properties can be retrieved either individually or as a group. 

II. Managed Beans: TTie managed bean repository can be queried for the existence of an individual 

s^n%°;'iSn':sl;s:'^''''^''""^^ 

m. JARs: The JAR repository can be queried for a Ust of JARs and their CLASSPATH ordering. The 
amount of free space m the repository can also be detennined. 
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IV. Java Cards: Card tenninals can be queried for the existence of Java Cards, and subsequently, each 
Java Card can be qu^ed for a list of Java Card applets. 

2. Bean Management: This process involves manipulating the set of managed beans that exist in the 
device. Managed beans can be added, replaced, and runoved. In effect, this service allows the 
application and service suite on the device to be customized remotely. Download services mclude 
automatic instantiation of new apphcatibns, automatic device restart (where required), and robust 
recovefy from foiled downloads. 

3. JAR Management While bean managem ent services automatically support downloading of new JARs 
associated with new applications and services, the gateway supports direct manipulation of JARs that 

- exist in the JAR repository. Specifically, the gateway supports reordering of JARs in Ihe JVM 
CLASSPATH, explicit deletion of JARs, and defragmentation of the JAR repository rtself. " 

4. Java Card Management: A Java Card that is inserted into an available card terminal can be managed 
.through the gateway. Specifically, ^plications can be downloaded to the card or deleted fi-om the card 

The gateway is implemented as an observer/controller managed/client bean pair, and as such, provides 
gateway capabilities to any server side controlling application. Within Alchemy™, gateway facilities are 
deployed into the probing tool tiurough a custom control/mterpreter interface. This interface acts as an 
example dq>loyment of the gateway that can be modified for a particular service environment, but also 
delivers full-featured gateway capabilities to &e developer. ^ 

9 Development Environment 

The underlying goal of Alchemy™ is to reduce the development cycle for intelligent devices by providing a 
software infrastructure an^ service suite that can be rapidly deployed onto a hardware reference platfonn. 
WhUe application development can be accomplished in any environment that supports Java, ultimately the 
Java code must be deployed into the target device on top of a properly configured RTOS/driver load. The 
Alchemy™ development environment supports this process through a set of utilities and tools that augment 
and enhance your preferred develoinnent environment, without imposing a specific environment or tool 
chain on the developer, furthermore, all Alchemy™ tools and utilities are written in Java and are delivered 
with full source code so that they can be tailored specifically to a preferred environment This means 
familiar development tools such as Java Integrated Development Envfronment (IDE), RTOS IDE, and code 
compactors such as the Embedded Java toolchain can be woven together into a seamless development 
environment tailored specifically to your needs. While the development environment is adaptable to any 
hardware target Alchemy™ provides specific integration for Touchstone™, and will work with it out of the 
box. 

Alchemy™ includes support for the following aspects of the development cycle: 

1 . Installation: Installation wizards and scripts are included that perform a complete installation of tfie 
Alchemy™ system into your development environment. 

2. Development, Alchemy™ includes a complete makefile structure that will build all AlchemyT*^ 
software components. This structure can be easily extended to include new applications and services. 

3 . Packaging: Alchemy™ provides packaging tools that perform the following functions: 

I. System Configuration Definition: Allows the developer to specify a particular hardware 
configuration that will be supported for a particular device. 

II. RTOS/Driver Configuration: Based on system configuration information, a RTOS/driver 
configuration can be automatically generated. 

III. Application Suite Definition: Allows the developer to define an application load for deployment 
onto a device. All application/service bean dependencies are automatically resolved to ensure a 
complete load. 

IV. Code Compaction and Ohfiiscation: Based on a defmed application load, code compaction and 
obfiiscation can be performed to minimize the merooiy footprint of the load. 

V. JAR Creation: Single or multiple JAR files can be produced for download to the device. 
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4. Targei Deployment Alchemy™ includes boot-loader fecilities for TouchstoneTf*^ that are capable of 
downloadmg a target software load to the device. Support is available for stand-alone loads as well as 
network-based loads. 

5. Test/Debug: As described earlier. Alchemy™ supports a remote observation and control environment 
for target testing and debugging. A number of test and device management tools are deployed under 
this architecture, including the probing tool and the gateway. 
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1 0 Appendix A - Touchstone™ 

TouchstoneTM is a two-board solution cx>mposed of a logfc board that contains central processing and the 
bulk of the I/O capabihdes, and a telephony board that includes the telephony and modem capabih'ties. The 
functional specification for each of these boards is given below. 

Logic Board Functionality 

1. MFC823(]^ Processor Socketed 

2. Core Memory 

• CSO boot Flash - 4 Mbytes of onboard Flash, Full 32 bit interface 

• Nand Flash - 4 to 8 Mbytes of onboard, 16 bit interface 

• Compact Flash memory expansion (2-48 Mbytes modules) 

• ATA interface vs. linear Flash will be dependant on existing Java 0S4C (i.e.. Chorus) support 

• 32Mbytes (max.) dedicated onboard SDRAM operating at the maximum processor bus speed. 

3. MPC82X LCD Controller 

• Common onboard LCD interface to provide complete access to all on chip LCD pins or dedicated 
LCD controller 

• Dedicated onboard LCD/CRT Controller with 256Kxl6 dedicated video DRAM, H/W provision 
only, EPSON SEDI355/6F0A -for part details vyww.eiti,epson.com 

Target LCD for Reference Board 



Manufacturer 


Part Number 


Pixels 


Display Area 
(H)x(V)mm 


Technology 


Sharp 


LQ64D341 


640 X 480 


130x97 


TFT Color 



4. ^ Party Resistive Touch screen 



5. Keypad, status indicator Interface 

• Offboard 2nm3 header to accommodate up to 6 x 6 keyscan matrix 

• I^C connections to provide 8 incremental GPIOs for LEDs (PCF8574) 

6. 1655DUART 

• Memory mapped UART with H/W flow control and dedicated interrupt 

• Dedicated interface to modem V.90 on telephony board 

7. . Communication Ports 

All Channels use the CPM capabilities and therefore will be constrained only by the performance 

of the CPM and its Time Division Multiplexing capabilities, 

'SCC2 

• IEEE 802.3 compliant (based on MC681 60 (Btheroet)) 

• IrDA (2.4K to 4Mb/s) - H/W only 

SMCl 

• 1 - 7816 compliant full size, smart card int^face 
SMC2 

• Non-isolated RS232 port 
USB 

• Dedicated keyboard interface - non compliant with USB host standards 
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I2C 

• 8 additional onboard GPIOs (PCF8574) 

• Digital potentiometer - LCD brightness control 

• 16KbEEPR0M 

SPI 

• Touch screen AfD interface 



8. Development and Debug Capabilities 

• MPC823 BDM port (non-isolated) 

• Dedicated Logic analyzer ports for primary MFC 823 address, data and control logic 

• Memory mapped debug LED*s 4 character, 5x5 ASCII interface 

Logic Block Diagram 



System memory 



Expansion 
memoiy 



KolscbuStfsie&mc 
lope not «lwi*n 



Teldphory 
Interface 



Onboard 
memoiy 



mm 




CRTOutput 



ToudvSoeen 



Logic board 

proof of port 

Dpdil*ilMirl).9» 



SUBSTITUTE SHEET (RULE 26) 



wo 00/077750 



PCT/CAOO/00703 



-39- 



Telephony Board Functionality^ 

Processor Independent Telephony Solution 
1-line or 2-line operation ~ user configurable . 

1. Line One Features - 

• Full featured handset/handsfree capability 

• Type I and irCaller ID features. 

• Full duplex handsfree 

• Shared Voice or m odem "( 1 -line scenario) 

• Isolated PSTN interface 

• Does not include DTAD or Voltage Message Waiting capability 

• Powered only operation i.e., no POTS operation 

2. J>5!P-based Handsfree and TrueSpeech ^ Audio (Line I onfy) 

• Integrated Full Duplex Handsfree 

• DTMPATone gen^ation and detection 

• Audio streaming de/compression as per DSP Group CT8021 (See table below) 

• Other than basic DSP driver support, functional driver support for listed incremental functions are . 
- - not supported. 



Supported Speech Coder 


Typical Application 


G.723.1 63 & 5.3 kbps 


H.324 for video conferencing over dial-up V.34 modems 
H.323 multi-media conferencmg over LANs and TCP/IP type 
''packet-data" networks (e.g., Internet) 


G.728 16 kbps 


H320 for video conferencing over ISDN 


TrueSpeech 4.8 & 4.8/4;l kbps 


Proprietary low bit rate coder 


16-bit oj 8-bit linear 
128 or 64 kbps 


Microsoft WAVE files 


G.7 1 1 Mu-Law/A-Law 
64 kbps 


Standard speech compression used in digital telephony systems 
(e.g..Tl/Bl) 


Downloadable Speech Coders 




TrueSpeech 8.5 
8.5 kbps 


DSP Group speech coder built into Microsoft Windows 95. 
Also used in some DSYD modems and Internet Telephones 


G.729A+B 
8 kbps 


Optional speech coder used in H.323 


G.722 
64Kbps 


7 KHz Wide bandwidth ADPCM audio coder used in H320 
aSDN) ' 



3. Line Two Features 

• Dedicated V.90 Modem interface (2-line scenario) 

• Isolated PSTN interface 

• Type 1- Caller ID 
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Telephony Block Diagram 



Block Diagram Vi.3 




AtMteSi Confidenlial -Not for esdemal dsblbution 
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We claim: 

1 . A method of providing a.multiple smart card simulator comprising: 

(i) storing a JBrst set of characteristics of a first smart card; 

(ii) creating a first smart card simulator simulating operation of said 
first smart card; 

(iii) storing a second set of characteristics of a second smart card; 

(iv) simulating operation of said second smart card thereby creating a 
second smart card simulator; 

(v) receiving a first input fiom a first smart card application; 

(vi) modifying said first input based on said first set of characteristics; 

(vii) sending a first modified input to said first smart card simulator; 

(viii) modifying said first input based on such second set of 
characteristics to form a second modified input; and. sending the 
second modified input to said second smart card simulator; 
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(ix) receiving a first output jfrom said first smart card simulator 
generated in response to said first modified input; 

(x) modifying said first output based on said first set of characteristics 
to form a first modified output; 

(xi) transmitting said first modified output to- said smart card 
applicatioi^ 

(xii) receiving a second output firom said second smart card simulator 
in response to said second modified input; 

(xiii) modifying said second output based on said second set of 
characteristics to form a second modified output; and 

(xiv) transmitting said second modified output to said smart card 
application. 

2. The method of claim 1 where said characteristics include one of the smart 
cards memory size, command sequence, error handling routine or quirks. 

3. The method of claim 1 fijrther comprising the steps: 
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(i) receiving a second input from a second smart card application; 

(ii) modifying said second ii^nt based on said first set of 
characteristics; 

(iii) sending a third modified input to said first smart card simulator; 

■(iv) receiving a third output from said first smart card simulator in 
req)onse to said third modified input; 

(v) modifying first said third output based on said first set of 
characteristics; 

(vi) transmitting said third modified output to said second smart card 
application. 

4. A method of simulating a multiple smart card environment comprising: 

(i) detecting a simulated smart card insertion (step 400); 

(ii) determining characteristics of the inserted card (step 405); 

(iii) notifying registered listeners (step 410); 
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(iv) detennining available appUcations (step 420^ 



(v) downloading to a simulated card and to a simulated terminal at 
least one smart card application (step 430) and 



(vi) repeating (steps 400 430). 
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Step too 


Storing first set of characteristics of first 
smart card. 




1 


Step 105 


Simulating operation of first smart card- 
creating a first smart card simulator. 




1 

t 


Step 110 1 


Storing second set of characteristics of 
second smart card. 




1 


Step 115 


Simulating operation of second smart card- 
creating a second smart card simulator. 




1 


Step 130 


Receiving Input from smart card 
application. 




1 


Step 140 


Modifying input from step 130 based on 
characteristics of first smart card. 




1 


Step 150 


Sending modified input to first 
smart card simulator. 




i 


Step 155 



Modifying input from step 130 based on 
characteristics of second smart card. 



Figure 1A 
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Step 160 1 


Sending modified Input to second 
smart card simulator. 




i 


Step 170 


Receiving output from first smart card 
simulator 




1 

t 


Step 180 


iviuufiyiii^ i^uifyui iiL/iii iiiol oil fell I CrcliO 

simulator with first set of characteristics of 
first smart card. 




i 


Steo 190 


Transmitting first modified output to smart 
card application. 






step 200 1 


nd/civii ly uui|jui iiuiii ocuuiiu smaiT caro 
simulator. 






1 Step 210 


Modifying output from second smart card 
simulator with second set of characteristics 
of second smart card. 




1 


Step 220 


Transmitting second modified output to 
smart card application. 





Figure IB 
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Step 300 


Receiving second input from second 
smart card application. 




1 

1 


Step 310 


Modifying second input based on first set 
of characteristics. 




1 

i 


Step 320 


Sf^nriinn thirrl mnHifiprI inniit fn firct cmorf 
luii 1^ uiiivj 1 1 iLiuiiic^w II i|JUl tu lllol olllan 

card simulator. 




1 
▼ 


Step 330 


Receiving a third output from the first 
smart card simulator. 






Step 340 


Modifying third output based on first set 
of characteristics. 




i 


Step 350 


Transmitting third modified output to 
second smart card application. 





Figure 2 
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otep 40U 


Generating a simulated smart card 
insGnion. 




1 

T 


otep 4Ud 


Determining characteristics of the 
inserted card. 




i 
T 


step 410 


Notifying registered listeners. 




1 


Step 420 


Determining available applications. 




1 


Step 430 


Downloading to a simulated card 
and to at least one simulated terminal 
smart card application. 






Step 440 


Repeating steps 400 to 430 





Figure 3 
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